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APPARATUS AND METHOD FOR OPERATING A COMMUNICATIONS 
DEVICE IN A MOBILE COMMUNICATIONS NETWORK, 

BACKGROUND 

TECHNICAL FIELD 

[0001] This application relates to UMTS (Universal Mobile Telecommunications 
System) in general, and to an apparatus and method for operating a communications 
device in a mobile communications network, 

DESCRIPTION OF THE RELATED ART 
[0002] The approaches described in this section could be pursued, but are not 
necessarily approaches that have been previously conceived or pursued. Therefore, 
unless otherwise indicated herein, the approaches described in this section are not 
prior art to the claims in this application and are not admitted to be prior art by 
inclusion in this section. 

[0003] In a typical cellular radio system, mobile user equipment (UE) communicates 
via a radio access radio network (RAN) to one or more core networks. User 
equipment (UE) comprises various types of equipment such as mobile telephones 
(also known as cellular or cell phones), lap tops with wireless communication 
capability, personal digital assistants (PDAs) etc. These may be portable, hand held, 
pocket sized, installed in a vehicle etc and communicate voice and/or data signals 
with the radio access network. 

[0004] The radio access network covers a geographical area divided into a plurality of 
cell areas. Each cell area is served by at least one base station, which may be referred 
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to as a Node B. Each cell is identified by a unique identifier which is broadcast in the 
cell. The base stations communicate at radio frequencies over an air interface with 
the UEs within range of the base station. Several base stations may be connected to a 
radio network controller (RNC) which controls various activities of the base stations. 
5 The radio network controllers are typically connected to a core network. 

[0005] UMTS is a third generation public land mobile telecommunication system. 
Various standardization bodies are known to publish and set standards for UMTS, 
each in their respective areas of competence. For instance, the 3 GPP (Third 
Generation Partnership Project) has been known to publish and set standards for GSM 
10 (Global System for Mobile Communications) based UMTS, and the 3GPP2 (Third 
Generation Partnership Project 2) has been known to publish and set standards for 
CDMA (Code Division Multiple Access) based UMTS. Within the scope of a 
particular standardization body, specific partners publish and set standards in their 
respective areas. 

15 [0006] Reference is also directed to 3 GPP TSG - Services and System Aspects 
"Vocabulary for 3GPP Specifications (Release 1999)" 3 GPP TS 21.905 v3.2.0 which 
defines terminology used in this document. 

[0007] Consider a wireless mobile device, generally referred to as user equipment 
(UE), that complies with the 3 GPP specifications for the UMTS protocol. The 3 GPP 
20 25.331 specification, v.3.15.0, referred to herein as the 25.331 specification, addresses 
the subject of UMTS RRC (Radio Resource Control) protocol requirements between 
the UMTS Terrestrial Radio Access Network (UTRAN) and the UE. The 3 GPP 
25.322 specification, v3.15.0, referred to herein as the 25.322 specification, addresses 
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the subject of UMTS RLC (Radio Link Control) protocol requirements between the 
UMTS Terrestrial Radio Access Network (UTRAN) and the UE. 
[0008] In accordance with clause 9.7.3 of the 25.322 specification, the RLC layer of 
the 3G UMTS stack may, in certain circumstances, discard an SDU (Service Data 
5 Unit). There are thus proposed strategies for handling the discard of an SDU. A 
number of such strategies are detailed below. 

[0009] Other aspects and features of the present invention will become apparent to 
those ordinarily skilled in the art upon review of the following description of specific 
embodiments of an apparatus and method for operating a communications device in a 
10 mobile communications network, 

[0010] BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] Embodiments of the present invention will now be described, by way of 
example only, with reference to the attached drawings, in which: 

Figure 1 is shows an overview of a network and a UE device.; 
15 Figure 2 is a block diagram illustrating an embodiment of a protocol stack provided in a UE; 

Figure 3 shows examples of actions taken in response to discard of an SDU; and Figure 4 is a 
block diagram illustrating a mobile device, which can act as a UE and co-operate with the apparatus 
and methods of Figures 1 and 2. 

The same reference numerals are used in different figures to denote similar elements. 

20 DETAILED DESCRIPTION OF THE DRAWINGS 

[0012] A method and apparatus for operating a communications device in a mobile 
communications network is described. In the following description, for the purposes 
of explanation, numerous specific details are set forth in order to provide a thorough 
understanding of the present invention. It will be apparent, however, to one skilled in 
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the art that the present invention may be practiced without these specific details. In 
other instances, well-known structures and devices are shown in block diagram form 
in order to avoid unnecessarily obscuring the present invention. 

[0013] The needs identified in the foregoing Background, and other needs and objects 
5 that will become apparent from the following description, are achieved by, in one 
aspect, a method for operating a communications device in a mobile communications 
network. In other aspects, the invention encompasses apparatus and a computer- 
readable medium configured to carry out the foregoing steps. In particular, the method 
may be implemented in a mobile telecommunications device, with or without voice 

10 capabilities, or other electronic devices such as handheld or portable devices. 

[0014] Referring to the drawings, Fig. 1 shows an overview of a network and a UE 
device. Clearly in practice there may be many UE devices operating with the network 
but, for the sake of simplicity, Fig. 1 only shows a single UE device 100. For the 
purposes of illustration, Fig. 1 also shows a network 1 19 having a few components. It 

15 will be clear to a person skilled in the art that in practice a network will include far 
more components than those shown. 

[0015] Fig. 1 shows an overview of the radio access network 119 (UTRAN) used in a 
UMTS system. The network 119 as shown in Fig. 1 comprises three Radio Network 
Subsystems (RNS) 2. Each RNS has a Radio Network Controller (RNC) 4. Each 
20 RNS 2 has one or more Node B 6 which are similar in function to a Base Transmitter 
Station of a GSM radio access network. User Equipment UE 100 may be mobile 
within the radio access network. Radio connections (indicated by the straight dotted 
lines in Fig. 1) are established between the UE and one or more of the Node Bs in the 
UTRAN. 
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[0016] The radio network controller controls the use and reliability of the radio 
resources within the RNS 2. Each RNC may also connected to a 3G mobile switching 
center 10 (3G MSC) and a 3G serving GPRS support node 12 (3G SGSN). 
[0017] An RNC 4 controls one or more Node B's. An RNC plus its Node B's together 
5 make up an RNS 2. A Node B controls one or more cells. Each cell is uniquely 
identified by a frequency and a primary scrambling code (primary CPICH in FDD, 
primary CCPCH in TDD). 

[0018] Generally in UMTS a cell refers to a radio network object that can be uniquely 
identified by a UE from a cell identifier that is broadcast over geographical areas from 

10 a UTRAN access point. A UTRAN access point is a conceptual point within the 
UTRAN performing radio transmission and reception. A UTRAN access point is 
associated with one specific cell i.e., there exists one UTRAN access point for each 
cell. It is the UTRAN-side end point of a radio link. A single physical Node B 6 may 
operate as more than one cell since it may operate at multiple frequencies and/or with 

15 multiple scrambling codes. 

[0019] Figure 2 is a block diagram illustrating an embodiment of a protocol stack 
provided in a UE. A Radio Resource Controller (RRC) block 200 is a sub layer of 
Layer 3 130 of a UMTS protocol stack 100. The RRC 200 exists in the control plane 
only and provides an information transfer service to the non-access stratum NAS 134. 

20 The RRC 200 is responsible for controlling the configuration of radio interface Layer 
1110 and Layer 2 120. When the UTRAN wishes to change the UE configuration it 
will issue a message to the UE containing a command to invoke a specific RRC 
procedure. The RRC 200 of the UE decodes this message and initiates the appropriate 
RRC procedure. Generally when the procedure has been completed (either 
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successfully or not) then the RRC sends a response message to the UTRAN (via the 
lower layers) informing the UTRAN of the outcome. It should be noted that there are 
a few scenarios where the RRC will not issue a response message to the UTRAN and, 
in those cases the RRC need not and does not reply. 
5 [0020] The document referred to above (3 GPP TSG - Services and System Aspects 
"Vocabulary for 3 GPP Specifications (Release 1999)" 3 GPP TS 21.905 v3.2.0) 
defines a radio bearer as "the service provided by Layer 2 for transfer of user data 
between User Equipment and UTRAN". 

[0021] The MAC entity at layer 2 accesses the services of the physical layer though 
10 entities known as 'Transport Channels". 

[0022] Each radio bearer can have one RLC entity in the uplink toward UTRAN and 
one in the downlink from UTRAN to higher layers of the UE. Of the radio bearers 
RBO-4 are used for signaling purposes and RB0 does not normally have its 
configuration changed. 

15 [0023] The RRC 200 of the UE 100 is also capable of acting upon instructions from 
users of its services, for example higher layers, to cause creation of an SDU (Service 
Data Unit). Such an SDU may for example comprise a response to the UTRAN to a 
request for reconfiguration of the UE. Such reconfiguration may include security 
configuration, radio bearer reconfiguration, transport channel reconfiguration or 

20 physical channel reconfiguration. 

[0024] Typically such SDUs are submitted by the RRC 200 to Layer 2, and to the 
RLC (Radio link Control) 130 for being passed via the MAC layer 140 to the physical 
layer 110. The intention is that the SDUs be passed through the air interface to 
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UTRAN, and up through corresponding layers to a layer of UTRAN that is a peer to 
the RRC 200 of the UE 100. 

[0025] The RLC 130 provides various modes for data transfer. One of these, 
'Acknowledged Mode 1 (AM), provides confirmation that all transmitted SDUs have 
5 been received successfully and uses various retry mechanisms to ensure this. 
Therefore, AM provides a reliable transport mechanism to higher layers, such as the 
RRC 200. 

[0026] As noted above, the RLC layer 130 may, in certain circumstances, discard an 
SDU as specified in specification 25.322 clause 9.7.3. However, the specification 
10 25.33 1 does not specify how the RRC 200 behaves if this happens. 

[0027] The RRC 200 may implement several strategies to cope with SDU discard. 
These are summarized below, and then explained in detail subsequently, with 
reference to the drawings. 

[0028] Two main cases can be identified for which the SDU discard behavior could 

15 be specified for the RRC in the 25.331 specification: 

[0029] 1 . An RRC response message is submitted to lower layers, and the RRC is not 
required to wait for acknowledgement or confirmation . In this case, the RRC 
procedure "ends", which means that any discard may be ignored. The network and the 
UE can rely on UTRAN (and its timeouts) to proceed. 

20 [0030] 2. An RRC response message is submitted to lower layers, and the RRC is 
required to await acknowledgement or confirmation, e.g. from a receiving process in 
UTRAN [acknowledged mode, AM, as noted above]. This mode may be specified 
for security changes and for transition to CELL_PCH and URA_PCH. In this case, 
the procedure will only end or be completed afterwards. So if the acknowledgement is 
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not received, the procedure is pending indefinitely if no behavior is specified where 
SDU_discard is configured. 

[0031] Additionally there are identified cases in which the 25.331 specification states 
that a NAS message has to be retransmitted. See for example par. 8.1.8.2a, for the 
case of initial direct transfer after re-establishment and a inter-system handover. This 
does not relate to "SDU discard" but to other RLC conditions, and is well specified. 
As such, this case is not addressed here. 

[0032] There are thus four different situations depending upon :a) whether 
SDU_DISCARD is configured or not, and b) whether the RRC is required to wait for 
acknowledgement or confirmation 
[0033] SDU DISCARD NOT configured: 

[0034] I) in case 1 (not waiting for acknowledgement) : no action, as discard will go 
unnoticed, and to rely on current procedures in UTRAN. 

[0035] II) in case 2 (acknowledged mode): In accordance with one aspect of the 
invention, the RRC may include a timer process, with a maximum time specified to 
await the successful confirmation of the transmission of the message submitted to the 
lower layer. Upon timeout, in accordance with the invention one of four behaviors 
may be initiated. If the lower layer returns a successful confirmation of having sent 
the SDU, the timer process is stopped, in one embodiment. 
SDU DISCARD configured ; 

[0036] III) in case 1 (not waiting for acknowledgement): Upon notification/indication 
of the discard condition, after the procedure has "ended' 1 , in accordance with the 
invention one of four behaviors may be initiated. 
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[0037] IV) in case 2 (acknowledged mode): Upon notification/indication of the 
discard condition while waiting for the successful confirmation of the submitted 
message to the lower layers, in accordance with the invention one of four behaviors 
may be initiated. 
5 [0038] Retry and Cell-update 

[0039] In a first class of embodiments, the RRC 200 re-submits the SDU (containing 
its message) to the RLC 130. This re-submission is performed N times, so that the 
SDU is submitted in all (N+l)times. If each time the SDU_DIS CARDED response is 
returned (or a timeout occurs first, see II above), then the RRC 200 behaves as though 
10 an RLC 130 un-recoverable error had occurred. The intention is that a Cell Update 
will be performed according to 25.331 specification, par. 8.3.1, with a cause of 'RLC 
unrecoverable error'. ( This behavior is illustrated by one of Figure 3a or Figure 3b 
followed by Figure 3c. ) 

[0040] To effect this, the UE 100 is set to a default configuration and state 
15 (cell_FACH) and the RRC 200 sends a CELL_UPDATE message over RB0 (Radio 
Bearer 0). This is a "reliable" method of communication in that, as noted above, 
generally RB0 normally has a static configuration and UTRAN remains receptive of 
messages on RB0 provided in connected-mode. 

[0041] The UTRAN can then send a CELL UPDATE CONFIRM message back to 
20 UE 100, using channels that are known to be set up as part of the default state 
(celMFACH). UTRAN then uses the CELL UPDATE CONFIRM to re-apply a 
configuration it was trying to apply when the problem happened, or alternatively it 
may take different action. 
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[0042] Par. 8.3.1.5 of 25.331 refers to the response made by UTRAN but the behavior 
of UTRAN is largely up to the implementer. 

5 [0043] In one example of the different action, the UTRAN can respond to the 'RLC 
unrecoverable error 1 cause by requesting re-establishment of radio-bearers. 

[0044] Moreover, the 'RLC unrecoverable error* cause means that if the RB has its 
default configuration, it will be configured for 'No Discard', and in that mode, when 

10 the criteria for SDU discard becomes true (for example if the SDU has been sent a 
certain number of times without a response), the RLC 130 will signal 'RLC 
unrecoverable error' to RRC 200 rather than signaling 'SDU discard'. Thus if the RB 
is configured in a non-default fashion such that Discard is configured, then the 
resulting behavior of the RRC will be very similar to the case where the RB did have 

1 5 the default configuration. 

[0045] Retry and return-to-idle: 

[0046] In the second class of embodiments the RRC 200 re-submits the SDU 
(containing its message) to the RLC 130. This re- submission is performed N times, so 
that the SDU is submitted in all (N+l) times. If each time the SDUJDISCARDED 
20 response is returned (or a timeout occurs first, see II above), then the RRC 200 returns 
to idle mode by releasing the RRC connection and other typical actions taken when 
entering idle mode. ( This behavior is illustrated by one of Figure 3a or Figure 3b 
followed by Figure 3d. ) 
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[0047] In a third class of embodiments, different actions occur depending upon a 
condition, e.g. whether security configuration was in progress or not. Where a security 
configuration is in progress, the RRC 200 re-submits the SDU (containing its 
message) to the RLC 130. This re-submission is performed N times, so that the SDU 
5 is submitted in all (N+l) times. If each time the SDUDISCARDED response is 
returned (or a timeout occurs first, see II above), then the RRC 200 returns to idle 
mode by releasing the RRC connection and other typical actions taken when entering 
idle mode. If no security configuration is in progress, the RRC 200 re-submits the 
SDU (containing its message) to the RLC 130. This re-submission is performed N 

10 times, so that the SDU is submitted in all (N+l) times. If each time the 
SDUDIS CARDED response is returned (or a timeout occurs first, see II above), then 
the RRC 200 behaves as though an RLC 130 un-recoverable error had occurred. 
[0048] It will be seen that this third class of embodiments is similar to the first and 
second class being employed alternatively depending upon whether security 

15 configuration is in progress or not. 

[0049] Retry and send a failure response : 

[0050] In the fourth class of embodiments, the RRC 200 re-submits the SDU 
(containing its message) to the RLC 130. This re-submission is performed N times, so 
that the SDU is submitted in all (N+l) times. If each time the SDUJDISCARDED 
20 response is returned or the timeout in case II), then the RRC sends a failure response 
message for the ongoing procedure (e.g. 

RADIO_BEARER_RECONFIGURATION_FAILURE in case of a 
RADIO BEARER RECONFIGURATION procedure). This behavior is similar to 
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other specified failure cases of such procedures. ( This behavior is illustrated by one 
of Figure 3 a or Figure 3b followed by Figure 3e. ) 

[0051] To keep the current behavior consistent for case III above, in one embodiment 
the UE considers the procedure as completed successfully, as the procedure has 
5 already ended in this case. Hence UE 100 does not try to revert to any old 
configuration. 

[0052] For cases II) and IV), the UE considers the procedures as not completed 
successfully, and finalizes the ongoing procedure in the way of other specified failure 
cases. 

10 [0053] If the transmission of the failure response message then fails, then the device 
may use any of the first or second class of embodiments as its next action, or 
alternatively adopt a further strategy, namely "Retry and do-nothing". In this strategy 
the RRC 200 re-submits the SDU (containing its message) to the RLC 130. This re- 
submission is performed N times, so that the SDU is submitted in all (N+l) times. If 

15 each time the SDU_DISCARDED response is returned or the timeout in case II), then 
the RRC considers the procedure has ended "successfully", and relies on current 
procedures in UTRAN. ( This behavior is illustrated by one of Figure 3 a or Figure 3b 
followed by Figure 3f. ) 

[0054] It is envisaged that for each of the classes of embodiments above the value of 
20 N may advantageously be set to 0. 

[0055] Thus for the first class of embodiments, as soon as SDUDIS CARDED is 
detected by the RRC 200 then a Cell Update would be performed. 
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[0056] Other values could be used but this would complicate conformance testing of 
the RLC/RRC protocol, and would also increase traffic loading during error 
situations. 

[0057] Turning now to Figure 4, Figure 4 is a block diagram illustrating a mobile 
device, which can act as a UE, and which is an exemplary wireless communication 
device. Mobile station 100 is preferably a two-way wireless communication device 
having at least voice and data communication capabilities. Mobile station 100 
preferably has the capability to communicate with other computer systems on the 
Internet. Depending on the exact functionality provided, the wireless device may be 
referred to as a data messaging device, a two-way pager, a wireless e-mail device, a 
cellular telephone with data messaging capabilities, a wireless Internet appliance, or a 
data communication device, as examples. 

[0058] Where mobile station 100 is enabled for two-way communication, it will 
incorporate a communication subsystem 211, including both a receiver 212 and a 
transmitter 214, as well as associated components such as one or more, preferably 
embedded or internal, antenna elements 216 and 218, local oscillators (LOs) 213, and 
a processing module such as a digital signal processor (DSP) 220. As will be 
apparent to those skilled in the field of communications, the particular design of the 
communication subsystem 211 will be dependent upon the communication network in 
which the device is intended to operate. For example, mobile station 100 may include 
a communication subsystem 211 designed to operate within the Mobitex™ mobile 
communication system, the DataTAC™ mobile communication system, GPRS 
network, UMTS network, or EDGE network. 
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[0059] Network access requirements will also vary depending upon the type of 
network 119. For example, in the Mobitex and DataTAC networks, mobile station 
100 is registered on the network using a unique identification number associated with 
each mobile station. In UMTS and GPRS networks, however, network access is 
associated with a subscriber or user of mobile station 100. A GPRS mobile station 
therefore requires a subscriber identity module (SIM) card in order to operate on a 
GPRS network. Without a valid SIM card, a GPRS mobile station will not be fully 
functional. Local or non-network communication functions, as well as legally 
required functions (if any) such as "911" emergency calling, may be available, but 
mobile station 100 will be unable to carry out any other functions involving 
communications over the network 119. The SIM interface 244 is normally similar to 
a card-slot into which a SIM card can be inserted and ejected like a diskette or 
PCMCIA card. The SIM card can have approximately 64K of memory and hold 
many key configuration 251, and other information 253 such as identification, and 
subscriber related information. 

[0060] When required network registration or activation procedures have been 
completed, mobile station 100 may send and receive communication signals over the 
network 119. Signals received by antenna 216 through communication network 119 
are input to receiver 212, which may perform such common receiver functions as 
signal amplification, frequency down conversion, filtering, channel selection and the 
like, and in the example system shown in Figure 4, analog to digital (A/D) 
conversion. A/D conversion of a received signal allows more complex 
communication functions such as demodulation and decoding to be performed in the 
DSP 220. In a similar manner, signals to be transmitted are processed, including 
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modulation and encoding for example, by DSP 220 and input to transmitter 214 for 
digital to analog conversion, frequency up conversion, filtering, amplification and 
transmission over the communication network 119 via antenna 218. DSP 220 not 
only processes communication signals, but also provides for receiver and transmitter 
control. For example, the gains applied to communication signals in receiver 212 and 
transmitter 214 may be adaptively controlled through automatic gain control 
algorithms implemented in DSP 220. 

[0061] Mobile station 100 preferably includes a microprocessor 238 which controls 
the overall operation of the device. Communication functions, including at least data 
and voice communications, are performed through communication subsystem 211. 
Microprocessor 238 also interacts with further device subsystems such as the display 
222, flash memory 224, random access memory (RAM) 226, auxiliary input/output 
(I/O) subsystems 228, serial port 230, keyboard 232, speaker 234, microphone 236, a 
short-range communications subsystem 240 and any other device subsystems 
generally designated as 242. 

[0062] Some of the subsystems shown in Figure 4 perform communication-related 
functions, whereas other subsystems may provide "resident" or on-device functions. 
Notably, some subsystems, such as keyboard 232 and display 222, for example, may 
be used for both communication-related functions, such as entering a text message for 
transmission over a communication network, and device-resident functions such as a 
calculator or task list. 

[0063] Operating system software used by the microprocessor 238 is preferably 
stored in a persistent store such as flash memory 224, which may instead be a read- 
only memory (ROM) or similar storage element (not shown). Those skilled in the art 
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will appreciate that the operating system, specific device applications, or parts thereof, 
may be temporarily loaded into a volatile memory such as RAM 226. Received 
communication signals may also be stored in RAM 226. 

[0064] As shown, flash memory 224 can be segregated into different areas for both 
computer programs 258 and program data storage 250, 252, 254 and 256. These 
different storage types indicate that each program can allocate a portion of flash 
memory 224 for their own data storage requirements. Microprocessor 238, in 
addition to its operating system functions, preferably enables execution of software 
applications on the mobile station. A predetermined set of applications that control 
basic operations, including at least data and voice communication applications for 
example, will normally be installed on mobile station 100 during manufacturing. A 
preferred software application may be a personal information manager (PIM) 
application having the ability to organize and manage data items relating to the user of 
the mobile station such as, but not limited to, e-mail, calendar events, voice mails, 
appointments, and task items. Naturally, one or more memory stores would be 
available on the mobile station to facilitate storage of PIM data items. Such PIM 
application would preferably have the ability to send and receive data items, via the 
wireless network 119. In a preferred embodiment, the PIM data items are seamlessly 
integrated, synchronized and updated, via the wireless network 119, with the mobile 
station user's corresponding data items stored or associated with a host computer 
system. Further applications may also be loaded onto the mobile station 100 through 
the network 119, an auxiliary I/O subsystem 228, serial port 230, short-range 
communications subsystem 240 or any other suitable subsystem 242, and installed by 
a user in the RAM 226 or preferably a non-volatile store (not shown) for execution by 
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the microprocessor 238. Such flexibility in application installation increases the 
functionality of the device and may provide enhanced on-device functions, 
communication-related functions, or both. For example, secure communication 
applications may enable electronic commerce functions and other such financial 
transactions to be performed using the mobile station 100. 

[0065] In a data communication mode, a received signal such as a text message or 
web page download will be processed by the communication subsystem 211 and input 
to the microprocessor 238, which preferably further processes the received signal for 
output to the display 222, or alternatively to an auxiliary I/O device 228. A user of 
mobile station 1 00 may also compose data items such as email messages for example, 
using the keyboard 232, which is preferably a complete alphanumeric keyboard or 
telephone-type keypad, in conjunction with the display 222 and possibly an auxiliary 
I/O device 228. Such composed items may then be transmitted over a communication 
network through the communication subsystem 211. 

[0066] For voice communications, overall operation of mobile station 100 is similar, 
except that received signals would preferably be output to a speaker 234 and signals 
for transmission would be generated by a microphone 236. Alternative voice or audio 
I/O subsystems, such as a voice message recording subsystem, may also be 
implemented on mobile station 100. Although voice or audio signal output is 
preferably accomplished primarily through the speaker 234, display 222 may also be 
used to provide an indication of the identity of a calling party, the duration of a voice 
call, or other voice call related information for example. 

[0067] Serial port 230 in Figure 4, would normally be implemented in a personal 
digital assistant (PDA)-type mobile station for which synchronization with a user's 
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desktop computer (not shown) may be desirable, but is an optional device component. 
Such a port 230 would enable a user to set preferences through an external device or 
software application and would extend the capabilities of mobile station 100 by 
providing for information or software downloads to mobile station 100 other than 
through a wireless communication network. The alternate download path may for 
example be used to load an encryption key onto the device through a direct and thus 
reliable and trusted connection to thereby enable secure device communication. 
[0068] Other communications subsystems 240, such as a short-range communications 
subsystem, is a further optional component which may provide for communication 
between mobile station 100 and different systems or devices, which need not 
necessarily be similar devices. For example, the subsystem 240 may include an 
infrared device and associated circuits and components or a Bluetooth™ 
communication module to provide for communication with similarly enabled systems 
and devices. 

[0069] When mobile device 100 is used as a UE, protocol stacks 246 include 
apparatus and a method for operating a device in a mobile communications network, 
the device operating using a protocol having a physical layer, and at least a higher and 
a lower intermediate layer, wherein the higher layer is arranged to submit an SDU to 
the lower layer for communication using the physical layer, wherein said SDU 
comprises information indicative of a process 

EXTENSIONS AND ALTERNATIVES 
[0070] In the foregoing specification, the invention has been described with reference 
to specific embodiments thereof. It will, however, be evident that various 
modifications and changes may be made thereto without departing from the scope of 
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the technique. The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 

[0071] It is to be noted that the methods as described have shown steps being carried 
out in a particular order. However, it would be clear to a person skilled in the art that 

5 the order of the evaluation is immaterial with respect to the operation of the method. 
The ordering of the steps as described herein is not intended to be limiting. 
[0072] It is also to be noted that where a method has been described it is also intended 
that protection is also sought for a device arranged to carry out the method and where 
features have been claimed independently of each other these may be used together 

10 with other claimed features. 



